home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-moore-mime-references-00.txt < prev    next >
Encoding:
Text File  |  1993-10-26  |  13.5 KB  |  369 lines
  1. Network Working Group                                        Keith Moore
  2. Internet Draft                                   University of Tennessee
  3.                                                          24 October 1993
  4.  
  5.  
  6.                  Multipart/References MIME Content-Type
  7.  
  8.                    draft-moore-mime-references-00.txt
  9.  
  10.  
  11. 1. Status of this Memo
  12.  
  13.    This document is an Internet Draft.  Internet Drafts are working
  14. documents of the Internet Engineering Task Force (IETF), its Areas, and
  15. its Working Groups.  Note that other groups may also distribute working
  16. documents as Internet Drafts.
  17.  
  18.    Internet Drafts are valid for a maximum of six months and may be
  19. updated, replaced, or obsoleted by other documents at any time.  (The
  20. file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil,
  21. describes the current status of each Internet Draft.)  It is not
  22. appropriate to use Internet Drafts as reference material or to cite them
  23. other than as "work in progress".
  24.  
  25.  
  26. 2. Abstract
  27.  
  28.    This memo defines a new MIME content-type "multipart/references",
  29. which can be used to denote a set of MIME contents, of which any one may
  30. reference the others by its MIME content-id.  This mechanism may be used
  31. by presentation languages that wish to be able to reference MIME
  32. objects, or by other applications (file transfer, authentication,
  33. delivery reports) which need to supply related information about another
  34. MIME object.
  35.  
  36.  
  37. 3. Introduction
  38.  
  39.    Several new MIME [1] -based applications are being developed which
  40. require data that is best represented (within a MIME message) as
  41. multiple MIME body parts.  Frequently, such applications simply need to
  42. "embellish" or provide additional information about one or more other
  43. objects, which themselves are naturally represented as MIME body parts.
  44. Examples of such applications include the following:
  45.  
  46.    + File transfer.  When using MIME to transfer a file, it is useful to
  47.      represent the file being transferred as a MIME body part (with
  48.      appropriate MIME content-type labelling), and provide additional
  49.      information (ownership, creation date, permissions, icon, or data
  50.      specific to a particular system) in a separate body part.  A MIME
  51.      mail reader could present the contents of the file being
  52.      transferred in addition to offering to store the file on the
  53.      recipient's file system.
  54.  
  55.  
  56.  
  57.  
  58. K. Moore                  Expires 24 April 1994                 [Page 1]
  59.  
  60.  
  61.  
  62. Multipart/References                                     24 October 1993
  63.  
  64.  
  65.  
  66.    + Authentication.  A separate body part could be used as a
  67.      certificate of authorship and integrity check, using protocols such
  68.      as PEM [2,3,4,5].
  69.  
  70.    + Delivery and receipt notifications.  A delivery status notification
  71.      (or receipt notification) may include both the original message,
  72.      and a separate body part indicating why the delivery of the message
  73.      failed.  The mechanism defined in this memo could be used to
  74.      illustrate the relationship between the two.
  75.  
  76.    + Hypertext systems.  It may be desirable to transmit a set of
  77.      hypertext documents which reference one another, in a single MIME
  78.      message.
  79.  
  80.    + Presentation languages.  Since MIME says little about how the
  81.      objects it carries are to be presented, this extension may be used
  82.      by presentation languages that wish to reference other MIME
  83.      objects.
  84.  
  85.    Although MIME [5] defines a content-id header which can be used for
  86. this purpose, it provides no mechanism by which one body part can
  87. reference another.  Neither does it provide a mechanism to indicate
  88. whether a particular body part should be presented by a mail reader,
  89. stored in a file (as in an attachment), or whether the body part is
  90. intended to be referenced by another body part.
  91.  
  92.    This memo thus defines:
  93.  
  94.    + a "multipart/references" content-type to be used to indicate a set
  95.      of body parts that may reference one another.
  96.  
  97.    + a new "internal" access-type for the message/external-body content-
  98.      type, which instructs the mail reader to present another body part
  99.      contained within the same multipart/references content.  (This is
  100.      intended to be used within multipart/alternative, as a fallback for
  101.      when better presentation languages are not supported.)
  102.  
  103.  
  104. 4.   The Multipart/References Content-Type
  105.  
  106.    The Multipart/References Content-Type is defined as follows:
  107.  
  108.       MIME type name: multipart
  109.       MIME subtype name: references
  110.       Required parameters: start
  111.       Optional parameters: none
  112.       Encoding considerations: No content-transfer-encoding may be used.
  113.       Security considerations: none
  114.  
  115.       NOTE IN DRAFT: this content-type needs a better name.  Suggestions
  116.       are welcome!
  117.  
  118.  
  119.  
  120. K. Moore                  Expires 24 April 1994                 [Page 2]
  121.  
  122.  
  123.  
  124. Multipart/References                                     24 October 1993
  125.  
  126.  
  127.  
  128.  
  129.    The "start" parameter contains the content-id of one of the immediate
  130. children of the multipart/references body part being defined (without
  131. the enclosing '<' and '>').  It indicates to the mail reader which of
  132. the components of the multipart/references should be presented.
  133.  
  134.    When presenting a multipart/references body part, the mail reader
  135. first scans all of the components contained within.  Then it presents
  136. the component whose content-id is indicated by the "start" parameter.
  137. The "start" component may then reference other body parts contained
  138. within the same, or an enclosing, multipart/references body part.  If an
  139. external program is responsible for presenting the "start" body part,
  140. the mail reader will run it in an environment from which it can obtain
  141. the other body parts (and associated headers) by using their content-id.
  142.  
  143.    Any component of a multipart/references body part (not just the
  144. "start" component) may reference any other component within the same (or
  145. an enclosing) multipart/references body part.  (The module charged with
  146. presenting the "start" component may cause other components of the
  147. multipart/references body part to be presented, which themselves
  148. reference other body parts.)
  149.  
  150.    Other than storing the information associated with each component of
  151. a multipart/references body part to allow for later retrival, and
  152. undoing any content-transfer-encoding applied to the component, no
  153. processing is performed on any of the components, before presenting the
  154. "start" component.
  155.  
  156.    NOTE:  This includes any "composite" content-types such as multipart,
  157.    message/external-body, or message/rfc822.  If such objects are
  158.    referenced by other components, they will obtain the original headers
  159.    and/or (decoded) body comprising the multipart, message/external-
  160.    body, or message/rfc822 body part.  The individual components or sub-
  161.    components of a composite CANNOT be directly referenced by another
  162.    body part, unless it first parses the components.
  163.  
  164.    A component of a multipart/references body part need not include a
  165. content-id header.  However, without such a header, there is no way for
  166. it to either be the "distinguished" component, or to be refernced by
  167. another component.  Such components will only be presented by a mail
  168. reader that does not implement this specification.
  169.  
  170.  
  171. 5.  The "internal" Access-Type for Message/External-Body
  172.  
  173.    A new access-type is defined for the MIME Message/External-Body
  174. content-type.  The "internal" access-type indicates that the actual body
  175. of this particular message/external-body body part, should be obtained
  176. from another body part contained within an enclosing
  177. multipart/references body part.  The mandantory parameter for this
  178. access-type is:
  179.  
  180.  
  181.  
  182. K. Moore                  Expires 24 April 1994                 [Page 3]
  183.  
  184.  
  185.  
  186. Multipart/References                                     24 October 1993
  187.  
  188.  
  189.  
  190.       CONTENT-ID -- the content-id of the body part being referenced
  191.  
  192.    The value associated with the content-id parameter should NOT include
  193. the enclosing '<' and '>' required by the content-id body part header.
  194.  
  195. NOTE IN DRAFT:  alternatives for the name "internal" are also solicited!
  196.  
  197.    When the internal access-type is used, the headers that appear in the
  198. body of the message/external-body part will normally be similar to the
  199. body part headers that appear with the referenced body part.  However,
  200. the headers need not be the identical, since it may be desirable to
  201. present the object slightly differently under different conditions.  In
  202. any case, when a message/external-body body part is presented, the
  203. headers appearing in the body of the message/external-body body part are
  204. used, rather than those of the referenced body part.
  205.  
  206. The "internal" access type is designed to allow "fallback" access to one
  207. or more components of a multipart/references body part.  For example, a
  208. hypothetical application/foo body part might reference other body parts
  209. A, B, and C.  If the recipient's mail reader doesn't support
  210. application/foo, the sender might want her to see A, B, and C anyway.
  211. So the message could be constructed as follows.  (In this example, A, B,
  212. C, and D are the content-ids of the components of the
  213. multipart/references body part.)
  214.  
  215.  
  216. multipart/references ; start=D {
  217.     A: [body-part-A]
  218.     B: [body-part-B]
  219.     C: [body-part-C]
  220.     D: multipart/alternative {
  221.      application/foo (which references A, B, and C internally)
  222.      multipart/mixed
  223.          message/external-body; access-type=internal; content-id=A
  224.          message/external-body; access-type=internal; content-id=B
  225.          message/external-body; access-type=internal; content-id=C
  226.     }
  227. }
  228.  
  229.  
  230. 6.  Security considerations
  231.  
  232.    Security considerations are not discussed in this memo.
  233.  
  234.  
  235. 7.  Acknowledgements
  236.  
  237.    This proposal is an amalgam resulting from ideas presented in several
  238. other approaches to this problem, including Harald Tveit Alvestrand's
  239. "multipart/related", Dave Crocker's "multipart/header-set", and Rens
  240. Troost's "content-disposition" documents.  (There are probably others
  241.  
  242.  
  243.  
  244. K. Moore                  Expires 24 April 1994                 [Page 4]
  245.  
  246.  
  247.  
  248. Multipart/References                                     24 October 1993
  249.  
  250.  
  251.  
  252. that I don't recall at the moment.)  Discussion on the ietf-822 and
  253. info-metamail mailing lists has helped to define the requirements for
  254. this proposal.
  255.  
  256.  
  257. 8.  References
  258.  
  259. [1] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
  260.     Extensions) Part One: Mechanisms for Specifying and Describing the
  261.     Format of Internet Message Bodies", RFC 1521, September 23 1993.
  262. [2] J. Linn, "Privacy Enhancement for Internet Electronic Mail:  Part
  263.     I:  Message Encryption and Authentication Procedures".  RFC 1421,
  264.     February 10 1993.
  265. [3] S. Kent, "Privacy Enhancement for Internet Electronic Mail:  Part
  266.     II:  Certificate-Based Key Management", RFC 1422, February 10 1993.
  267. [4] D. Balenson, "Privacy Enhancement for Internet Electronic Mail:
  268.     Part III:  Algorithms, Modes, and Identifiers", RFC 1423, February
  269.     10 1993.
  270. [5] B. Kaliski, "Privacy Enhancement for Internet Electronic Mail:  Part
  271.     IV: Key Certification and Related Services", RFC 1424, Febryary 10,
  272.     1993.
  273.  
  274.  
  275. 9. Author's address
  276.  
  277. Keith Moore
  278. University of Tennessee
  279. 107 Ayres Hall
  280. Knoxville, TN 37996-1301
  281. USA
  282.  
  283. email: moore@cs.utk.edu
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306. K. Moore                  Expires 24 April 1994                 [Page 5]
  307.  
  308.  
  309.  
  310. Multipart/References                                     24 October 1993
  311.  
  312.  
  313.  
  314. Appendix. Implementation suggestion
  315.  
  316. This proposal requires that the "modules" responsible for presenting a
  317. body part be able to reference other body parts.  The mechanisms by
  318. which this might be done vary considerably from one system to another
  319. (e.g. logical names on VMS, shared file descriptors on UNIX).  Because
  320. dissimilar systems often share code nowadays, there is some advantage in
  321. having a system-independent way to provide such access.  Here is a
  322. suggestion for how this might be done in a relatively painless manner.
  323.  
  324. When a mail reader encounters a multipart/references body part, it
  325. proceeds to scan each of the components.  Each component's headers are
  326. stored in a temporary file, and the body part (after undoing any
  327. content-transfer-encoding) is stored in a separate temporary file.  The
  328. names of the files are based on the content-id of the body part being
  329. stored.
  330.  
  331. Since content-IDs may contain special characters not allowed in a file
  332. name, or may be longer than the length of a file name, they may be
  333. mapped into legal file names as follows:
  334.  
  335. 1. Remove the '<' and '>' enclosing the content-id.
  336. 2. Apply the MD5 digest algorithm (see RFC 1321) to the result.
  337. 3. Separate the resulting 128-bit digest into four groups of 32 bits
  338.    each, and exclusive-or together all four groups, producing a 32-bit
  339.    result.
  340. 4. Encode the resulting 32-bit quantity as 8 hexadecimal, upper case
  341.    characters.
  342. 5. If necessary, truncate the resulting character string so that it fits
  343.    within the limits of the local file system (leaving room for a four
  344.    character filename suffix).
  345. 6. Append the string ".HDR" to produce the filename to contain the
  346.    header, and ".BDY" for the filename to contain the body part.
  347. 7. The calling program should remove the temporary files after the sub-
  348.    program completes its work.
  349.  
  350. The author hopes this method will be sufficient for any modern file
  351. system.  File name collisions are presumed to be unlikely, but paranoid
  352. implementors might want to modify the filename suffix should collisions
  353. occur.
  354.  
  355. An application programmer's interface should be provided to handle the
  356. details of translating file names and manipulating the resulting files.
  357. Such an interface could also be extended "underneath" to provide more
  358. efficient access where the operating system supports it, e.g. by sharing
  359. memory between processes.
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368. K. Moore                  Expires 24 April 1994                 [Page 6]
  369.